1. Field of the Invention
This invention relates to the simulation of digital circuits such as, for example, digital integrated circuits.
2. Description of the Prior Art
Digital circuit simulation involves simulating the functions of a digital circuit in software running on a general purpose computer. The technique is particularly useful when applied to complex digital integrated circuits such as microprocessors, for two main reasons. One reason is that the simulation allows the microprocessor designers to test the design before starting the relatively expensive semiconductor fabrication process for the circuit. Another reason is that the simulation can be used during the development of hardware and software peripherals intended to work with the microprocessor, so that the peripherals can be made available as soon as possible after fabrication of the microprocessor.
Several digital circuit simulation computer programs are commercially available. Four examples are "Vantage Spreadsheet", "Synopsys Vss", "Cadence Verilog" and "Modeltech V-System".
These four digital circuit simulation packages use dedicated logic simulation programming languages or an open standard language such as "VHDL", but they also allow blocks of simulation code written in, for example, the C programming language, to be interfaced to the main simulation written in the language of the main or primary simulator. This facility is referred to by various names as listed below, and is described in the following publications, which are hereby incorporated into this application by reference:
______________________________________ Vantage "STYX" Vantage Spreadsheet Styx Spreadsheet: Reference Manual, v5.0, 1993 Synopsys Vss: "C language VSS Expert Interfaces Manual, interface" ("CLI") 1994 Cadence Verilog; "Programming Cadence Programming language interface" Language Interface Reference ("PLI") Manual, vols 1 and 2, v1.6a, 1992 Modeltech V- "Foreign language V-System Manual, v4.3, January System: interface" 1995 ______________________________________
With each of the packages described above, blocks of C code can be written to simulate relatively small blocks of the microprocessor such a pipeline unit, a program counter, or even an arithmetic logic unit. Each block is then interfaced directly to the simulation package to provide a simulation of the entire microprocessor.
An example of this arrangement is shown in FIG. 1 of the accompanying drawings, which is a schematic diagram showing the interaction of several of such simulation blocks 10, 20, 30 with a primary simulator 40 in a previously-proposed digital circuit simulator. The primary simulator could be, for example, one of the four commercially available simulators described above.
Each of the simulation blocks 10, 20, 30 is written in the C programming language and simulates the operation of a respective part of a microprocessor. For example, a simulation block could simulate a multiplier unit, a status register, an instruction pipeline and so on.
In general, each simulation block will require and will generate two classes of input and output data. One of these classes, which will be referred to as "internal" data, is data representing internal signals passed between different component parts of the digital circuit. In the case of simulation of a microprocessor, examples of such signals are internal register values or zero flags. In this case, when the integrated circuit is fabricated as a semiconductor product, internal signals such as these would not be routed to input/output pins or connections of the integrated circuit; they would simply be passed between internal components.
The other class of data is referred to as "external" data, and this represents electrical signals which are normally passed to and from the outside world when the circuit is fabricated as a semiconductor product. Examples of external signals are a clock signal and an external address bus.
However, because in FIG. 1 the simulation blocks are connected to one another only via the primary simulator 40, both internal and external signals must be passed to and from the primary simulator 40. As described above, this means that details of the internal operation of the integrated circuit, in particular details of the internal signal traffic and the identity and function of the simulation blocks, which would otherwise be kept confidential, have to be disclosed to users of the simulator.
FIG. 1 illustrates a further feature of previously proposed simulators, which is the use of "veneers" to tailor the interface between the simulation blocks 10, 20, 30 and the particular primary simulator 40 in use. The veneers 50, 60, 70 allow the simulation blocks 10, 20, 30 and so on to be prepared in a generic way, so that only a relatively small amount of work is required to add the veneers for communication with a particular primary simulator 40.
FIG. 2 of the accompanying drawings is a schematic circuit diagram corresponding to the arrangement of FIG. 1. FIG. 2 illustrates a number of examples of simulation blocks (e.g. condition unit, multiplier, arithmetic logic unit (ALU), pipeline), interconnected via the primary simulator 40. Accordingly, although these blocks would communicate directly in a fabricated integrated circuit, in the simulator arrangement the blocks have to communicate via the primary simulator 40.
This previously proposed arrangement has two main disadvantages. One is that each code block must be made compatible with the correct simulation package, either by writing the code in a particular way or by applying the correct veneer for each code block. Another possibly more significant disadvantage stems from the fact that the simulation code is often distributed by the microprocessor designers to third party companies before the microprocessor is placed on the market. Because the individual code blocks represent relatively small parts of the microprocessor and have to be accompanied by information specifying the internal signals exchanged between the blocks, the microprocessor designer is actually distributing far more detailed information about the internal operation of the microprocessor than is actually required by a peripheral designer. In fact, in many cases much of the information which has to be distributed in this way would otherwise be kept confidential by the microprocessor designer even after the fabricated product is placed on the market. While this information is generally not abused by the recipient, the fact that the detailed design information is supplied to third party peripheral designers does expose the microprocessor designer to possible breaches of confidence by unauthorised copying or distribution of the design information.